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REMARKS 

Claims 1 - 7, 18 - 23, 26, 27 and 30 - 49 were pending in the application. By this paper. 
Applicant has amended Claims 27 and 30. Hence, Claims 1 - 7, 18 - 23, 26, 27. and 30 - 49 are 
5 presented for examination herein. 

§101 Rejections 

Claims 27 and 30 - Per page 2 of the Office Action, Claims 27 and 30 each stand 

rejected under 35 U.S.C. § 101 as it is alleged that the claimed inventions are directed to non- 
10 statutory subject matter. Applicant has herein amended the aforementioned claims so that they 
now positively recite a device containing "a computer readable medium comprising 
instructions" per the Examiner's suggestions at page 2 of the Office Action. 

Applicant respectfully submits that the current amendments overcome the 
aforementioned 35 U.S.C. § 101 rejections. 

15 

§103 Rejections 

1. Per page 3 of the Office Action, Claims 1, 18, 23, 26, 27, 30, 31, 38, 43 and 49 
each stand rejected under 35 U.S.C. § 103 as being unpatentable over Duckwall (U.S. Patent No. 
6,266,334, hereinafter "Duckwall '334") in view of Duckwall (U.S. Patent No. 5,495,481, 
20 hereinafter "Duckwall '481"). In response thereto, Applicant provides the following remarks. 

Claims 1 and 23 - With regards to Claims 1 and 23, Applicant respectfiilly traverses the 
Examiner's assertion that Duckwall '334 in view of Duckwall '481 renders unpatentable 
Applicant's Claim 1 and 23 inventions. Specifically, Applicant submits that neither Duckwall 
25 '334 nor Duckwall '481, whether viewed alone or in combination, teaches or suggests 
concatenating a bogus ack packet to the plurality of packets of the first type 

The bulk (if not the entirety) of the Examiner's argument seems to rely on an 
interpretation in which the first type of packet comprises an ''ack packet '\ i.e. that ack packets 
may comprise asynchronous packets characterized by the absence of a requirement that an 
30 unarbitrated response or ack packet be sent in response to transmission of a packet of the ack 
packet type. 
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The Examiner alleges that Duckwall '334 teaches or suggests at Fig. 4, steps 98 and 100 
that ''if there is no packet of the second type to be sent, then concatenating a bogus ack packet to 
the plurality of packets of the first type'\ However, step 98 of Duckwall '334 clearly teaches the 
transmission of a "bare ack packet''; i.e., an ack packet that is not concatenated with anything at 
5 all. The comment with regards to step 100 which states **ack packet (and concatenated data 
packet, if any) received by other nodes", as shown in Duckwall '334, only refers to the case 
where the concatenated data packet at decision tree step 96 is routed in the "yes" result to step 
106. Accordingly, step 100 is not saying that the bare ack packet is concatenated with a packet of 
the first type, as seemingly implied by the Examiner. See e.g. Col. 6, lines 17-21 of Duckwall 
10 '334. 

Duckwall '481 is equally devoid of any teaching or suggesting of the aforementioned 
claimed methodology as well. 

Accordingly, Applicant respectfully submits that the Examiner's rejection is improper 
and that Claims 1 and 23, as previously presented, distinguishes over both the teachings of 
1 5 Duckwall '334 and Duckwall '48 1. 

Claims 18, 26 and 30 - With regards to Claims 18, 26 and 30, Applicant respectfully 
traverses the Examiner's assertion that Duckwall '334 in view of Duckwall '481 renders 
unpatentable Applicant's Claim 18, 26 and 30 inventions. 
20 Specifically, Applicant submits that Duckwall '334 in view of Duckwall '481 does not 

teach ''if fly-by concatenation is not permitted then sending the received packet''. The Examiner 
alleges that this is taught at Col. 2, lines 25 - 45 of Duckwall '334 and then provides selected 
passages from this citation. Col. 2, lines 25 - 45 of Duckwall '334 states in full: 

25 ''Thus, in the instance where a node wanted to concatenate an SlOO 

packet onto it's acknowledge packet, it would be prevented from doing so if the 
acknowledge packet had been sent at S200 or S400, Sending the acknowledge 
packet at S200 instead of SI 00 will save 40 ns or 60 ns respectively, but missing 
the concatenation opportunity will cost at least the time required for normal 

30 arbitration, typically hundreds of ns , IEEE 1394a will allow a node to 

concatenate a packet onto a passing upward (towards the root) bound 
acknowledge packet. This is very similar to the acknowledge-packet 
concatenation mentioned previously, but it uses an acknowledge packet generated 
by some other node entirely. The speed-bandwidth considerations of normal 

35 acknowledse-packet concatenation apply here equally: sending an S200 
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acknowledge packet precludes concatenation of an SI 00 packet onto the 
acknowledge packet. Finally, IEEE J 394a will allow nodes to begin bus 
arbitration as soon as an acknowledge packet is detected (i.e., transmitted, 
received and/or repeated)... " {Emphasis added}. 

5 

In other words, Duckwall '334 does not teach or suggest "// Jly-by concatenation is not 
permitted then sending the received packet '\ rather Duckwall '334 teaches: ''Hf concatenation is 
prevented, then arbitration must be performed^ The Examiner states that sending the received 
packet is taught at Col. 2, lines 24 - 45 where it states ''passing upward... bound acknowledge 

10 packet"', however, the Examiner is respectfully ignoring the fact that in the same paragraph 
Duckwall '334 also states ''speed-bandwidth considerations of normal acknowledge-packet 
concatenation apply here equally; sending an S200 acknowledge packet precludes concatenation 
of an SI 00 packet onto the acknowledge packet" as it applies to IEEE 1394a and accordingly, 
the same situation that prevented concatenation in the previous citation cited by the Examiner 

15 applies equally to the situation cited by the Examiner in support of the Examiner's contention 
that Duckwall '334 teaches Applicant's claimed functionality. 

In addition, and wholly separate from the argument presented above, neither Duckwall 
'334 nor Duckwall '481 appear to teach or suggest "a bosus ack packet". The Examiner appears 
to take the position that "a bogus ack packet" is the same thing as an ack packet (see page 14 of 

20 the Office Action); however Applicant submits that such an interpretation ignores the plain 
meaning of the claimed terminology and is an unreasonable interpretation wholly inconsistent 
with Applicant's specification as filed. See e.g. MPEP § 2111. Accordingly, Applicant 
respectfully submits that the Examiner's rejection is improper and that Claims 18, 26 and 30, as 
previously presented, distinguishes over both the teachings of Duckwall '334 and Duckwall '481 

25 on this independent basis as well. 

Claim 27 - With regards to Claim 27, Applicant respectfully traverses the Examiner's 
assertion that Duckwall '334 in view of Duckwall '481 renders unpatentable Applicant's Claim 
27 invention. 

30 Specifically, Applicant submits that neither Duckwall '334 nor Duckwall '481, whether 

viewed alone or in combination, teaches or suggests ''concatenating a bogus ack packet to the 
plurality of packets of the first type 
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Per page 5 of the Office Action, the Examiner appears to interpreting data of the first type 
to comprise ''an ack packet'' and a bogus ack packet as a ''bare ack packet '\ Applicant submits 
that the ''bare ack packet'' as taught by Duckwall '334 is not concatenated with anything and 
that therefore the Examiner's rejection of Claim 27 is improper. See also the discussion above 
5 with regards to Claims 1 and 23 and Col. 6, lines 17-21 of Duckwall '334. 

Applicant further notes that the Examiner's interpretation within Applicant's Claim 27 
rejection of the Office Action is internally inconsistent; i.e. at one point the Examiner is 
interpreting data of the first type to comprise "an ack packet", and later in the analysis interprets 
data of the first type to be equivalent to a "concatenated data packet, concatenated local data 
10 packet". Accordingly, Applicant respectfully submits that the Examiner's argument rejecting 
Applicant's Claim 27 invention as unpatentable is flawed on this individual and distinct basis as 
well. 

Accordingly, Applicant respectfully submits that the Examiner's rejection is improper 
and that Claim 27, as previously presented, distinguishes over both the teachings of Duckwall 
15 '334 and Duckwall '481 on multiple bases. 

Claim 31 - With regards to Claim 31, Applicant respectfully traverses the Examiner's 
assertion that Duckwall '334 in view of Duckwall '481 renders unpatentable Applicant's Claim 
31 invention. Specifically, Applicant submits that neither Duckwall '334 nor Duckwall '481, 

20 whether viewed alone or in combination, teaches or suggests "concatenating a false 
acknowledgement packet to the plurality of packets of the first type 

The Examiner's argument seems to rely on an interpretation in which the first type of 
packet comprises an "ack packet "\ i.e., that ack packets may comprise asynchronous packets 
characterized by the absence of a requirement that an acknowledgement packet be sent in 

25 response to transmission of a packet of the ack packet type. 

The Examiner alleges that Duckwall '334 teaches or suggests at Fig. 4, steps 98 and 100 
that "if no packet of the second type needs to be sent, concatenating a false acknowledgement 
packet". However, step 98 of Duckwall '334 clearly teaches the transmission of a "bare ack 
packet", i.e. an ack packet that is not concatenated with anything at all. The comment with 

30 regards to step 1 00 which states "ack packet (and concatenated data packet, if any) received by 
other nodes '\ as shown in Duckwall '334, only refers to the concatenated data packet case where 
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the decision tree at step 96 is routed in the yes direction to step 106. Accordingly, step 100 is not 
saying that the bare ack packet is concatenated with a packet of the first type, as seemingly 
implied by the Examiner. See e.g. Col. 6, lines 17-21 of Duckwall '334. Duckwall '481 is 
equally devoid of any teaching or suggesting of the aforementioned claimed methodology as 
5 well. Accordingly, Applicant respectfully submits that the Examiner's rejection is improper and 
that Claim 31, as previously presented, distinguishes over both the teachings of Duckwall '334 
and Duckwall '481. 

Claims 38 and 49 - With regards to Claims 38 and 49, Applicant respectfully traverses 
10 the Examiner's assertion that Duckwall '334 in view of Duckwall '481 renders unpatentable 
Applicant's Claim 38 and 49 inventions. Specifically, Applicant submits that Duckwall '334 in 
view of Duckwall '481 does not teach ''if concatenation is not permitted, sending the received 
packet''. The Examiner alleges that this is taught at Col. 2, lines 25 - 45 of Duckwall '334 and 
then providing selected passages from this citation. Col. 2, lines 25 - 45 of Duckwall '334 states 
15 inflill: 

''Thus, in the instance where a node wanted to concatenate an SI 00 
packet onto it's acknowledge packet, it would be prevented from doing so if the 
acknowledge packet had been sent at S200 or S400. Sending the acknowledge 

20 packet at S200 instead of SI 00 will save 40 ns or 60 ns respectively, but mis sins 

the concatenation opportunity will cost at least the time required for normal 
arbitration, typically hundreds of ns . IEEE 1394a will allow a node to 
concatenate a packet onto a passing upward (towards the root) bound 
acknowledge packet. This is very similar to the acknowledge-packet 

25 concatenation mentioned previously, but it uses an acknowledge packet generated 

by some other node entirely. The speed-bandwidth considerations of normal 
acknowledse-packet concatenation apply here equally; sending an S200 
acknowledge packet precludes concatenation of an SI 00 packet onto the 
acknowledge packet. Finally, IEEE 1394a will allow nodes to begin bus 

30 arbitration as soon as an acknowledge packet is detected (i.e., transmitted, 

received and/or repeated).,. " {Emphasis added}. 

In other words, Duckwall '334 does not teach or suggest "if concatenation is not permitted, 
sending the received packet", rather Duckwall '334 teaches if concatenation is prevented, then 
35 arbitration must be performed. The Examiner states that sending the received packet is taught at 
Col. 2, lines 24 - 45 where it states "passing upward... bound acknowledge packet '\ however. 
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the Examiner is ignoring the fact that in the same paragraph Duckwall '334 also states ''speed- 
bandwidth considerations of normal acknowledge-packet concatenation apply here equally; 
sending an S200 acknowledge packet precludes concatenation of an SI 00 packet onto the 
acknowledge packet" as it applies to IEEE 1394a and accordingly, the same situation that 
5 prevented concatenation in the previous citation cited by the Examiner applies equally to the 
situation cited by the Examiner in support of the Examiner's contention that Duckwall '334 
teaches Applicant's claimed functionality. 

In addition, and wholly separate from the previous argument presented above, neither 
Duckwall '334 nor Duckwall '481 appear to teach or suggest "a false response packet''. The 

10 Examiner appears to take the position that "a false response packet" is the same thing as an ack 
packet at page 14 of the Office Action; however, Applicant submits that such an interpretation 
ignores the plain meaning of the claimed terminology and is an unreasonable interpretation 
wholly inconsistent with Applicant's specification as filed. See e.g. MPEP § 2111. 

Accordingly, Applicant respectfully submits that the Examiner's rejection is improper 

15 and that Claims 38 and 49, as previously presented, distinguishes over both the teachings of 
Duckwall '334 and Duckwall '481 on this independent basis as well. 

Claim 43 - With regards to Claim 43, Applicant respectfully traverses the Examiner's 
assertion that Duckwall '334 in view of Duckwall '481 renders unpatentable Applicant's Claim 
20 43 invention. Specifically, Applicant submits that neither Duckwall '334 nor Duckwall '481, 
whether viewed alone or in combination, teaches or suggests to "concatenate a false 
acknowledgement packet to the plurality of packets of the first type 

The Examiner's argument seems to rely on an interpretation in which the first type of 
packet comprises an "ack packet "\ i.e., that ack packets may comprise asynchronous packets 
25 characterized by the absence of a requirement that an acknowledgement packet be sent in 
response to transmission of a packet of the ack packet type. 

The Examiner alleges that Duckwall '334 teaches or suggests at Fig. 4, steps 98 and 100 
that ''if no packet of the second type needs to be sent, concatenate a false acknowledgement 
packet". However, step 98 of Duckwall '334 clearly teaches the transmission of a "bare ack 
30 packet" \ i.e., an ack packet that is not concatenated with anything at all. The comment with 
regards to step 100 which states "ack packet (and concatenated data packet, if any) received by 

-14- 



Application No. 
Filed 



10/728,185 
Decem})er 3„2003 



other nodes", as shown in Duckwall *334, only refers to the concatenated data packet case where 
the decision tree at step 96 is routed in the yes direction to step 106. Accordingly, step 100 is not 
saying that the bare ack packet is concatenated with a packet of the first type, as seemingly 
implied by the Examiner. See e.g. Col. 6, lines 17 - 21 of Duckwall '334. Duckwall '481 is 
5 equally devoid of any teaching or suggesting of the aforementioned claimed methodology as 



Accordingly, Applicant respectfully submits that the Examiner's rejection is improper 
and that Claim 43, as previously presented, distinguishes over both the teachings of Duckwall 
'334 and Duckwall '481. 



Other Remarks 

Applicant hereby specifically reserves all rights of appeal (including those under the Pre- 
Appeal Brief Pilot Program), as well as the right to prosecute claims of different scope in another 
continuation or divisional application. 



the purposes of more clearly and particularly describing and claiming the invention and not for 
purposes of overcoming art or for patentability. The Examiner should infer no (i) adoption of a 
position with respect to patentability, (ii) change in the Applicant's position with respect to any 
claim or subject matter of the invention, or (iii) acquiescence in any way to any position taken by 
20 the Examiner, based on such cancellations or additions. 

Furthermore, any remarks made with respect to a given claim or claims are limited solely 
to such claim or claims. If the Examiner has any questions or comments which may be resolved 
over the telephone, he is requested to call the undersigned at (858) 675-1670. 

25 Respectfully submitted, 



well. 
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Applicant notes that any claim cancellations or additions made herein are made solely for 
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